COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂TO MASINTER@PARC 13:46 2-Oct
C00013 ENDMK
C⊗;
∂TO MASINTER@PARC 13:46 2-Oct
InterLisp Queries
Larry -
	I've a few questions, related to InterLisp, (as you might have guessed).
First: I noted that neither PUTD nor /PUTD (nor MOVD, /MOVD) call
MARKASCHANGED.  Is this a feature, or a bug?  You may remember I went
through the hassle of advising these functions, (as well as a slew of others)
to help with my bookkeepping; then abandoned these when you told me the 
FILEPKGTYPE(FNS WHENCHANGED (...)) hack would solve these problems.
Turns out it doesn't.

Next: Is there any way I can enter LISP which does NOT read (and execute)
the INIT.LISP file on my login directory?  (Short of first renaming that file?)
I know I can then UNDO that GREET command, but I feel guilty making
LISP do all that work for naught.
[A particular problem motivated this question: 
The FILE package never finds out about the files which are LOADed
during this start-up, rendering these files next to impossible to alter.
I tried simply tacking the names of these files onto FILELST.
This makes the functions on these files "readonly" -- EDITF will now read
in these files, but a subsequent MAKFILE begins by (re)reading in the
file, wiping out the changes.
The only way I know of altering these files is to first LOAD them by hand.
Certainly there must be a better way...]

I've been burned a few times when I edited a broken functions -- for indirect
reasons, sometimes these changes go away when I later unbreak the function;
and other times I get a funny message when the function executes, because 
the BREAK1 calls seems to remain.
Anyway, I thought it might make sense to have EDITF consider first unbreaking
the function, (ie only if the user approves), and then rebreaking it after
editing.
I thought advising EDITF would dod the trick.  That, however, fails:
the UNBREAK command is aborted with a message that this function is now being
edited.  So now the question:  How does it know? And how can I circumvent
it, permitting me to unbreak that function?

My final question is about Rand-Ai's <LISP>LISP.EXE.133 in particular.
There are a lot of bells and whistles present in SCORE's version which are
not included there -- such as the LISPXMACROS
EV, EP, EF, and CONN.  Will subsequent releases of Lisp include these
niceties; or will these only be customizations?

---
Hope these pesky questions aren't too bothersome -- but, in each case,
I couldn't find anything in the manual which helped, nor did any
of the locals have any suggestios.

Thanks,
Russ

∂02-Oct-81  1448	Masinter at PARC-MAXC 	Re: InterLisp Queries 
To: Russell Greiner <RDG at SU-AI>
cc: masinter

∂TO MASINTER@PARC 15:40 2-Oct
Thanks.  Rebuttal:
** Thanks for your rapid comments.  My suggestions/requests for clarifications/
** volunteered information/etc appear below, prefaced by **s.

The decision about which things call MARKASCHANGED is heuristic. If you are
defining functions and want the file package to know about it, you need to call
DEFINE or else do the MARKASCHANGED explicitly. Any place in the SYSTEM
which defines functions (e.g. MAKEFN macro or COPYDEF or MOVD from top
level or DEFINE, etc.) do wind up doing a MARKASCHANGED.
	** NO - it was a top level MOVD not calling my WHENCHANGED function
	** that alerted me to this problem.
	** (Perhaps it was because MOVD was advised?)
	** Anyway, I reentered my advise to do that MARKASCHANGED.
	** It still is a hassle figuring that, for example,
	** what LOAD or ADVISE generates is not really changed,
	** but that any thing produced by a MOVD is.  Oh well, ...

At PARC our <LISP>INIT.LISP has a hack in it where if you typed LISP<lf>
rather than LISP<cr> it won't do the user's GREET. 
	** It would be nice if
	**	LISP;foo<cr>
	** read in the file foo.
	** (I often want to read in the INIT.LISP from my CONNECTed directory,
	** rather than my login directory. Typing
	**	LISP;INIT.LISP<cr>
	** would do that.)
	** For "upwards compatibilty", the file <login-dir>INIT.LISP should
	** be read in if both the file name and the ";" were omitted.
	** To read in nothing, type
	**	LISP;<cr>
	** (I imagine this would come for almost nothing -- thanks to the
	** errorset around the load, and the fact that few users have a file
	** names NIL, or "", or whatever the transmitted name would end up
	** being.)

I don't see what is wrong with doing a LOADFROM on the files you want to
edit if they are loaded by GREET. It may be a hassle, but having the files be
"real" turned out to be more of a hassle more often. Please don't just tack them
onto FILELST! The results are unpredictable...
	** Oh, does LOADFROM really do the right thing here?  I'll confess I
	** never tried it -- figuring it was aleady being done each time
	** I called EDITF on those functions; and realizing that that didn't
	** work anyway.

There is some complicated mechanism in the EDITF-BREAK interaction which is
"supposed" to work reasonably. If you have an example where it doesn't I'd like
to see it and try to fix the interaction. 
	** Is this your saying you don't know why BREAK wouldn't break any
	** function now being edited, either?
	** Anyway, next time I get clobbered I'll let you know.  As I mentioned
	** it's usually because some (BREAK1 ...) carcass which isn't cleaned up.

Appelt or someone hacked up something so that the LISP.EXE at SCORE was
really a SYSOUT into which a lot of packages had already been loaded. I imagine
one could do the same thing at RAND-AI. If you find out what was done, let me
know and I will let other sites know about it.
	** Yes - I plowed thru that when trying to move these things to
	** Rand-Ai a few months ago.  He has a function which spits out a
	** INIT.LISP file, which is then read in when initializing LISP.
	** Check the files
	**	INIT.LISP and MAKEINIT.LSP, both on [SCORE]<LISP>.

Larry

(p.s. Are you SCORE's new Interlisp liason? I heard Appelt had quit....)
	** Actually he used words like "Graduated" - but I see you weren't fooled...
	** No - I personally wouldn't mind; but Doug (Lenat) would be annoyed
	** to see me spending such time on non-thesis things.

** New material:
When Keith noted that <LISP>LISP.EXE and <SUBSYS>LISP.EXE were identical, and
each occupying about 600 pages, he changed <SUBSYS>LISP.EXE into a (3 page)
system "macro", which simply goes to <LISP>LISP.EXE..  It seems to work, so far.
I just wanted to ask if this is safe, in general.

Thanks again,
	Russ